Repository navigation
Let journal entries be edited in the TUI - #266
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Adds in-TUI journal editing while preserving rich HTML and handling read/write failures safely.
Changes:
- Adds journal edit, save, cancel, and removal flows.
- Preserves editable HTML and refreshes entries after saves.
- Adds focused journal editor tests.
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
internal/tui/journal.go |
Implements journal loading, editing, saving, and notices. |
internal/tui/journal_form.go |
Adds the journal textarea form and key bindings. |
internal/tui/journal_test.go |
Covers editor lifecycle, rich content, and failures. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Journal readers can create or edit the selected day without leaving the TUI, while preserving rich journal HTML, keeping repeated saves structurally stable, and preventing failed reads from opening an unsafe blank editor.
Review readiness: ✅ Yes
Risk: 🟡 Medium — journal writes can replace rich content, so the editor round-trips HEY’s editable HTML and keeps failed drafts open
Decision: None
✅ Change — selected journal days can be created, updated, or removed
Before
After
The form uses
eto edit,ctrl+sto save, andescto cancel. An empty save mirrorshey journal writeby removing the day’s entry.✅ Evidence — focused behavior and repository checks pass locally
trix-contentwrappers to the server’s single presentation wrapper and kept the normalized text unchanged.e, editing it without presentation wrappers, saving withctrl+s, and repeating an unchanged save without wrapper growth.✅ Scope — existing SDK operations and CLI behavior stay authoritative
Included: TUI editing for the selected journal day, successful-save refresh, stable removal of
trix-contentpresentation wrappers before updates, rich-content preservation, and recoverable save errors.Not included: a rich-text terminal editor or SDK/API changes. Existing CLI journal behavior is unchanged.
➖ Delivery — no migration, configuration, dependency, or rollout work
The change uses the existing
Journal().GetandJournal().Updateoperations. Rollback is a code revert.✅ Review decision — no unresolved decision
Rich entries appear as editable HTML without HEY’s
trix-contentpresentation containers, so repeated unchanged saves retain links, formatting, and attachments without accumulating wrappers. Review should begin with that token-preserving normalization and with failed-read and failed-save handling before the form lifecycle.✅ Review path — journal flow, form, then behavioral coverage
internal/tui/journal.go— read/write flow and request-lane handlinginternal/tui/journal_form.go— textarea behavior and key bindingsinternal/tui/journal_test.go— behavioral and failure-state evidenceOrigin and supporting links: Basecamp card